IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. The architecture and general features of the IMS are described generally in 3GPP specification TS 23.002 and, in more detail, in TS 23.228. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP).
The IMS is logically structured into a so-called “core network” layer and a so-called “service layer”. The core network layer is implemented by functional entities which are briefly described below. The service layer essentially comprises “Application Servers” arranged to provide services to user terminals (referred to hereinafter as User Equipment (UE)). These Application Servers are connected via the IMS, and/or arranged to mediate in the provision of services by executing specific service-based logic, such as to divert an incoming multimedia session in certain circumstances.
Of particular interest here is the Serving Call Session Control Function (S-CSCF) which is present within the IMS core network. The S-CSCF performs session control services for a UE and maintains a session state according to the (SIP) signalling exchanged with a UE for supporting the services originated and/or terminated by the UE. The S-CSCF can also communicate with Application Servers (ASs) of the IMS service layer to handle services for users. Further details of the functionality of a S-CSCF are given in chapter 4.6.3 of 3GPP specification TS 23.228.
Whilst the 3GPP organisation originally proposed the IMS in the context of mobile networks, it is noted that the IMS also finds application in respect of fixed access networks. A typical operator architecture may utilise the IMS to seamlessly deliver services over both a fixed and a mobile network.
Charging in the IMS is facilitated by interfaces between IMS nodes within a given network, and a network operator billing system. Both online and offline charging are typically (although not always) provided for within a given IMS network. Within the IMS, charging information is generated at a Charging Trigger Function (CTF). A CTF may be implemented, for example, in an AS responsible for implementing a particular service. [CTFs may also be implemented, for example, in CSCFs as well as in other SIP network entities.] FIG. 1 illustrates schematically IMS network entities that are involved in establishing a session, e.g. an MMTel session, between two users A and B. Various components, such as P-CSCFs, I-CSCFs, etc are omitted for simplicity. In the illustrated example, users A and B are registered with respective, different IMS networks. CTFs are implemented at the SIP ASs on both sides of the network, and may send charging information (i.e. charging events and/or charging requests) to an offline charging function (Charging Data Function/Charging Gateway Function, CDF/CGF) via the Rf interface. Alternatively, the CTF may send charging information to an Online Charging System (OCS) via the Ro interface. The online and offline charging functions may additionally receive charging information from other CTFs in the IMS network. The online and offline charging functions may, in turn, send Charging Data Records (CDRs) to the respective operators billing domain. Network operators' billing domains must exchange charging data in order to reconcile their accounts and to determine, on a regular basis, how much money needs to be exchanged.
In the case of a given IMS session, CTFs on both sides of the session will simultaneously be sending charging information to one or other of the respective offline and online charging functions. In the case, for example, of an MMTel voice call, where user A is the calling party and user B is the called party, the originating side will typically generate charging information such that the CDRs provided to the originating side billing domain will identify that money is to be paid to the terminating side network operator. The terminating side will, on the other hand, cause CDRs to be provided to the terminating side billing domain identifying that money is owed to the terminating side network operator by the originating side network operator. Information is exchanged between the two billing domains to allow for inter-operator settlements. Further details of IMS charging mechanisms are given, for example, in 3GPP TS 32.229.
Typically, the originating side billing domain will apply a given tariff for the session. It will be aware of how much it is required to pay to the terminating side in respect of the session and the applied tariff will take this into account. The terminating side billing system will be aware of what it should be paid for the session, although it will probably not be aware of the total charge made to user A. Of course, more complex scenarios exist, e.g. where one or both of user A and user B are roaming in visited networks.
As well as the more usual services where a calling party (or more generally speaking, the session initiating party) is charged for a service, telecommunication networks commonly provide for so-called premium rate and free-phone services. A special case of the free-phone service is the sponsored call service according to which a session initiating party is charged only for a proportion of the total service cost. Thus for example, a calling party calling a mobile number may pay only a fixed line local tariff, whilst the remainder of the cost is paid by a network operator or “owner” of the mobile number. Whilst such services, including sponsored call services, are usually offered in respect of voice calls, they are in most cases also applicable for messaging (e.g. SMS and MMS) or even web browsing services.
These alternative charging scenarios are generally handled by essentially “static” agreements configured in the billing systems. For example, in the architecture of FIG. 1 where user A is the calling party, the billing domain of user A will be aware that calls made to a number prefixed with “0800” are freephone calls, and that user A should not be charged for the call, with all charges being accepted by the network of user B.
This approach to handling alternative charging scenarios in the IMS is not particularly flexible. It is difficult to manage as tariffs and number series must be preconfigured across a possibly large number of billing domains, and, at the same time, is unlikely to allow fine grain control of billing, e.g. it might not be possible to apply a special tariff to a specific number (as opposed to a number series). The known approach is also unlikely to allow individual users, including domestic users and corporate users, to apply their own alternative charging scenarios.